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Abstract 


In  a  world  of  rapidly  advancing  commercial  technology,  the  U.S.  military  often  still 
struggles  to  deliver  state-of-the  art  command  and  control  (C2)  infonnation  technologies 
to  warfighters  and  commanders.  Some  recent  success  stories  include  the  Tactical  Ground 
Reporting  (TIGR)  system,  the  Command  Post  of  the  Future  (CPOF),  and  the  Combined 
Information  Data  Network  Exchange  (CIDNE).  These  cases  can  be  characterized  using  a 
Kline  “Chain-Linked”  model  of  innovation,  with  very  strong  iterative  links  between 
research  and  development  (R&D)  and  “markets”  (military  end  users  in  this  context). 
These  initiatives  also  made  effective  use  of  available  commercial  technology  and  dis¬ 
played  “edge  innovation”  by  end  users.  The  initiatives  identified  pressing  needs  with  a 
minimum  of  process  formalism  and  then  filled  those  needs  quickly,  with  dedicated 
development  teams  for  continual  refinement.  They  often  temporarily  bypassed  nonnal 
procurement  channels.  Initial  deployments  were  often  limited,  with  “at-risk”  adoption  by 
commanders,  allowing  crucial  in-theater  experimentation  and  feedback  loops  in  the 
development  process.  As  the  technologies  proved  useful,  deployment  expanded.  Despite 
potential  problems  in  interoperability  and  security  and  in  conflicts  with  the  military 
bureaucracy,  such  “Kline-like”  innovation  shows  promise  for  some  C2  technologies. 


Introduction 


A  number  of  successful  information  technology  (IT)  developments  related  to  U.S.  mili¬ 
tary  command  and  control  (C2),  including  the  Tactical  Ground  Reporting  (TIGR)  system, 
the  Command  Post  of  the  Future  (CPOF),  and  the  Combined  Information  Data  Network 
Exchange  (CIDNE),  have  displayed  some  common  characteristics  in  their  development 
processes.  Among  these  are  strong  iterative  links  between  end  users  and  personnel  in 
research,  development,  and  engineering  and  a  relatively  high  degree  of  innovation  by  end 
users  themselves.  The  development  of  these  technologies  can  be  characterized  using  a 
Kline  “Chain-Linked”  model  of  innovation,  as  we  discuss  below.  The  technologies  were 
also  characterized  by  relatively  rapid  deployment  to  fill  pressing  user  needs  and  were 
often  initially  deployed  “at  risk,”  temporarily  bypassing  the  normal  U.S.  military  acqui¬ 
sition  process. 

The  Linear  Innovation  Model 


A  simple  linear  model  of  innovation  holds  that  fundamental  scientific  research  leads  to 
new  ideas  that  can  ultimately  form  the  basis  for  new  products.  In  this  model,  scientific 
research  creates  new  knowledge;  applied  research  and  development  (R&D)  focuses  and 
applies  the  knowledge;  development  and  engineering  functions  create  products  based  on 
the  knowledge;  and  manufacturing  and  production  departments  then  take  over  and  make 
the  products.  There  is  an  implied  unidirectional  chain  of  causality  between  science  and 
technology  (S&T),  and  between  technology  and  production.1  Fig.  1  depicts  a  simple 
linear  model. 


1  Carafa  et  al.  (2009). 


1 


Scientific 

Research 


Development/ 
Engineering 


Manufacturing/ 

Production 


» 


Marketing/ 

Distribution 


Figure  1.  The  so-called  “Linear”  model  of  innovation  (adapted  from  Kline  and  Rosenberg2).  In  this  model, 
fundamental  scientific  research  leads  to  development,  then  engineering  and  production,  and  finally  mar¬ 
keting  and  distribution  of  new  products.  While  scientific  research  can  certainly  provide  the  knowledge 
required  to  create  new  classes  of  products,  the  innovation  process  is  often  more  complex  and  involves  more 
feedback  than  indicated  by  the  simple  linear  model. 

Although  rarely  enunciated  explicitly,  a  mindset  similar  to  the  linear  model  was  prevalent 
during  the  post-war  era  of  “Big  Science.”  Discussions  of  the  linear  model  frequently 
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make  reference  to  a  famous  report  produced  by  Vannevar  Bush  at  the  end  of  the  Second 
World  War,4  in  response  to  a  letter  from  President  Truman.  Bush  argued  that  the  way  to 
create  truly  new  products  and  entirely  new  industries,  and  thereby  ensure  a  long-term 
increase  in  the  standard  of  living,  was  to  discover  new  scientific  knowledge,  which  would 
seed  future  developments.  The  Bush  report  was  a  well-reasoned  and  successful  attempt  to 
argue  that  scientific  research  is  a  public  good  deserving  public  support.  It  should  be 
noted,  however,  that  Bush  did  not  draw  a  diagram  like  the  one  in  Fig.  1,  nor  did  he  use 
the  phrase  “linear  model”  in  his  report.5  The  “linear  model”  may  have  been  in  the  back  of 
many  people’s  minds  for  decades,  but  it  was  not  until  the  1980s  that  it  was  explicitly 
written  down  as  such,6  and  then  only  as  a  strawman  to  be  refined  and  improved.7 

The  linear  model  is  not  “wrong.”  It  tells  part  of  the  story  of  how  successful  innovation 
can  occur,  but  it  does  not  always  tell  the  whole  story.  Innovation  is  generally  a  more 
complex  process,  with  considerable  feedback  between  science,  technology,  manufac¬ 
turing,  and  marketing. 

The  Kline  “Chain-Linked”  Model  of  Innovation 


The  Model 


o 

The  Kline  Chain-Linked  model  of  innovation,  depicted  in  Fig.  2,  recognizes  a  number  of 
complexities  in  the  innovation  process.  While  it  is  possible  for  the  innovation  chain  to 
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Kline  and  Rosenberg  (1986). 

3  For  example,  Carafa  et  al.  (2009). 

4  Bush  (1945). 

5  There  is  also  no  evidence  that  Mr.  Bush  was  unaware  of  the  true  complexity  of  the  innovation 
process. 

6  For  example,  Kline  (1985);  Kline  and  Rosenberg  (1986). 

7  Edgerton  (2004);  Godin  (2005a,b);  Godin  (2006);  Gulbrandsen  (2008). 
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Kline  (1985);  Kline  and  Rosenberg  (1986);  variations  and  extensions  of  the  model  are 
discussed,  for  example,  by  Kameoka,  Ito,  and  Kobayashi  (2001). 
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Figure  2.  The  Kline  (“Chain-Linked”)  model  of  innovation  (adapted  from  Kline  and  Rosenberg9).  The 
model  depicts  innovation  as  a  complex  process  in  which  S&T  may  make  important  contributions  at  several 
different  points.  The  main  chain  of  innovation  is  indicated  by  C  and  proceeds  from  an  initial  perceived 
need  (“potential  market”)  through  the  various  technical  stages  culminating  in  a  product.  However,  C  is  not 
the  only  possible  path.  There  are  feedback  loops  /between  the  technical  stages  and  between  the  marketing 
and  technical  stages.  A  particularly  important  feedback  loop  F  is  the  one  between  marketing  and  the  initial 
conceptual  stage.  Another  path  (K  and  R)  involves  interaction  with  the  existing  base  of  scientific  know¬ 
ledge  ( K)  to  solve  problems  and  obtain  new  ideas  or,  if  necessary,  the  performance  of  new  scientific 
research  (R).  K  and/or  R  may  occur  at  any  of  the  stages  leading  to  a  product — or  may  not.  Path  D  represents 
a  potential  direct  link  between  scientific  research  and  the  invention  and  design  stage,  as  in  the  linear  model. 
Path  1  indicates  feedback  to  scientific  research  by  the  products  of  innovation  (e.g.,  the  telescope  aiding 
Galileo’s  fundamental  work  in  astronomy).  S  indicates  the  stimulation  of  new  research  in  sciences  under¬ 
lying  the  product  area  of  the  particular  innovation  process  in  question. 

proceed  sequentially  (C  in  the  figure),  this  is  not  necessarily  or  generally  the  case.  In 
addition,  new  knowledge  is  not  typically  the  driver  for  initiating  the  process;  rather,  the 
driver  is  the  identification  of  an  unfulfilled  market  need.  There  are  numerous  feedback 
loops  if  and  F  in  the  figure)  between  the  various  sequential  stages.  Questions  raised  in 
production,  for  example,  may  stimulate  new  design  and  testing.  Issues  raised  in  design 
and  test  may  necessitate  new  analysis  and  invention.  A  particularly  important  feedback 
loop  ( F)  is  between  marketing,  the  final  stage  of  the  main  chain,  and  the  first  conceptual 
stage — the  identification  of  the  unfulfilled  need.  The  market  helps  refine  the  conception 
of  the  need,  and  hence  to  guide  the  innovation  and  invention. 


9  Kline  and  Rosenberg  (1986). 
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When  a  problem  arises  at  any  stage  in  the  process  and  feedback  loops  to  earlier  stages 
cannot  solve  it,  the  practitioners  may  query  the  world’s  base  of  scientific  knowledge 
(path  K  in  Fig.  2)  for  a  solution.  If  the  knowledge  base  does  not  yield  a  solution,  new 
research  may  be  performed  or  commissioned  ( R ).  Occasionally,  fundamental  research 
may  give  rise  directly  to  an  innovation  chain  (path  D),  as  in  the  linear  model.  It  is  also 
possible  for  the  products  of  an  innovation  chain  (e.g.,  scientific  instruments)  to  be  used 
by  practitioners  performing  basic  research  (path  I). 

Overall,  the  Kline  model  recognizes  that  technology  can  move  backwards  as  well  as  for¬ 
wards  in  the  innovation  process  and  that  science  can  contribute  to  every  stage.  The  model 
also  recognizes  the  importance  of  direct  and  indirect  links  between  research  and 
marketing.  Implicit  in  the  model  is  the  crucial  importance  of  end-user  feedback.  Research 
may  set  the  course  directly  for  subsequent  innovation  stages,  but  it  will  not  always  do  so. 
Unfulfilled  needs  (marketing)  often  set  the  course,  and  research  contributes  to  resolving 
problems — because  previous  research  has  added  to  the  accumulated  store  of  knowledge 
and  because  new  research  may  answer  questions  directly  and  uncover  new  ones. 

Cautions  in  Applying  the  Model  to  Military  Systems 

The  Kline  model  probably  applies  best  in  a  commercial  industrial  context.  One  must 
exercise  some  caution  when  using  it  to  describe  developments  in  the  United  States 
Department  of  Defense  (DoD).  What,  after  all,  constitutes  a  “market”  in  the  case  of  the 
DoD?  How  are  “market  signals”  generated  and  perceived?  These  questions  are  difficult 
to  answer  in  the  case  of  long-term,  multibillion-dollar  procurement  programs.  The  DoD, 
after  all,  is  a  monopsony,  with  a  limited  supplier  base. 

However,  for  individual  IT  capabilities  that  have  identifiable  end  users  in  the  field,  the 
analogy  is  more  apt.  To  an  important  extent,  the  end  users,  rather  than  the  acquisition 
establishment,  constitute  the  “market.”  Feedback  from  those  users  can  serve  as  the  basis 
for  Kline-like  iteration.  IT  capabilities  of  the  kind  discussed  in  this  paper  have  at  least 
some  of  the  character  of  commercial  packages.  They  are  developed  to  fill  perceived 
needs  of  users  who  may  then  accept  or  reject  them  and  whose  experiences  may  modify 
them. 

Cases 


Case  1:  Tactical  Ground  Reporting  (TIGR)  System 


Introduction  and  Features 

The  TIGR  System  is  a  tactical  situational  awareness  system  developed  by  the  U.S. 
Defense  Advanced  Research  Projects  Agency  (D  ARP  A). 10  It  allows  operators  to  share 


Ewy  et  al.  (2009);  Corrin  (2010);  Maeda  (2010);  Magnuson  (2007). 
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facts,  issues,  suppositions,  and  lessons  learned  via  map-referenced  multimedia.  It  enables 
troops  heading  out  on  new  assignments  to  benefit  from  the  knowledge  gained  by  their 
predecessors.  TIGR’s  graphical,  map-based  user  interface  is  highly  intuitive  and  allows 
data  such  as  voice  recordings,  digital  photos,  and  Global  Positioning  Systems  (GPS) 
tracks  to  be  easily  collected  and  searched.  The  system  also  features  a  purpose-built  data 
distribution  architecture  that  minimizes  the  load  on  sparse-bandwidth,  intermittent  tac¬ 
tical  networks  while  allowing  digital  imagery  and  other  multimedia  data  to  be 
exchanged.11  This  network’s  science  and  engineering  content  distinguishes  TIGR  from 
typical  commercial  products  that  are  not  designed  for  the  harsh  tactical  environment.  Ini¬ 
tial  evaluations  of  TIGR  took  place  in  2006.  By  2010,  it  was  being  used  by  all  U.S.  Army 

12 

Brigade  Combat  Teams  in  Iraq  and  Afghanistan. 


Using  TIGR,  patrol  leaders  can  conduct  company-  and  patrol-level  intelligence  prepara¬ 
tion  of  the  battlefield  (IPB)  before  and  after  missions.  By  clicking  on  icons  and  lists,  they 
can  see  the  locations  of  key  buildings  (e.g.,  mosques,  schools,  and  hospitals)  and  retrieve 
information  (e.g.,  location  data  on  past  attacks,  geo-tagged  photos  of  houses  and  other 
buildings,  and  photos  of  suspected  insurgents  and  neighborhood  leaders).  They  can  listen 
to  civilian  interviews  and  watch  videos  of  past  maneuvers.  TIGR  was  expressly  created  to 
support  horizontal  infonnation  sharing  at  relatively  low  echelons  of  U.S.  ground  force 
operations.  As  a  staff  officer  from  the  First  Brigade  Combat  Team  put  it,  “It  is  a  bit 
revolutionary  from  a  military  perspective  when  you  think  about  it,  using  peer-based 
information  to  drive  the  next  move....  Normally,  we  are  used  to  our  higher  headquarters 
telling  the  patrol  leader  what  he  needs  to  think.”  TIGR  ran  initially  on  laptop  computers 
at  fixed  sites  to  which  soldiers  would  return  after  a  patrol.  Work  has  been  underway  to 
increase  mobility  and  also  to  increase  integration  of  information  from  new  sources,  such 
as  unmanned  aerial  vehicles  (UAVs). 


Development 


An  important  TIGR  predecessor  was  CavNet,  a  local  system  developed  internally  by  the 
U.S.  Army  1st  Cavalry — a  true  case  of  “edge  innovation.”14  CavNet  was  a  collection  of 
blogs  and  forums  that  allowed  junior  leaders  down  to  the  squad  level  to  share  infonnation 
with  one  another  across  the  entire  division.  In  one  well-publicized  use  of  the  network,  a 
patrol  leader  in  Baghdad  learned  that  insurgents  were  wiring  posters  of  Moqtada  al-Sadr 
to  explode  when  U.S.  soldiers  took  them  down,  and  he  posted  the  infonnation.  Another 
officer  elsewhere  in  the  city  read  the  information  and  alerted  his  soldiers,  who  discovered 
some  of  the  rigged  posters  and  safely  removed  them. 15 


1 1  Ewy  et  al.  (2009). 

12  Maeda  (2010). 

13  Quoted  by  Talbot  (2008). 

14  Teamey  (2008). 

15  Baum  (2005). 
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Although  CavNet  improved  information  sharing,  it  did  not  have  a  friendly,  well-inte¬ 
grated  human-machine  interface  or  a  reliable  database  for  multimedia  and  reports.16  To 
fill  these  needs  and  others,  soldiers  from  the  1st  Cavalry  teamed  with  DARPA  to  work  on 
what  would  be  later  called  TIGR.  A  DARPA  program  manager  (PM)  began  interacting 
directly  with  soldiers  returning  from  Iraq  and  was  able  to  refine  her  appreciation  of  the 
operational  need.  She  was  also  able  to  confirm  the  willingness  of  battalion-level  leaders 
to  accept  new  tools  to  fill  that  need. 


A  team  of  programmers  was  assigned  to  work  directly  with  soldiers  in  developing  spe¬ 
cific  TIGR  features  in  prioritized  categories.  First  Cavalry  personnel  tested  the  system  in 
exercises  at  the  unit’s  home  station  and  at  Army  training  centers.  Working  directly  with 
soldiers  who  would  actually  use  the  software  on  deployment  accelerated  the  development 
process  and  also  enabled  developers  to  focus  on  the  most  crucial  features  and  capabilities. 
The  PM  has  been  quoted  as  saying  “the  functionality  in  TIGR  has  changed  and  increased 
in  various  ways  based  on  feedback  from  the  troops.”17  One  result  was  an  extremely  intui¬ 
tive  and  effective  user  interface,  similar  to  that  found  in  Google  Maps  and  in  social  net¬ 
working  sites — familiar  paradigms  for  young  soldiers.  The  system  made  creative  and 

effective  use  of  available  commercial  technologies,  initially  using  a  Microsoft  infrastruc- 
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ture  and  a  graphical  user  interface  (GUI)  provided  by  Internet  Explorer. 


TIGR  did  not  begin  as  a  formal  Program  of  Record  and  did  not  have  time  to  go  through 
all  the  usual  military  acquisition  channels.  Compelling  operational  needs  demanded  its 
presence  in  theater,  and  commanders  in  the  field  made  the  decision  to  employ  it.  The 
Army  did  not  provide  formal  acquisition  support  for  fielding.  The  Army  also  did  not 
initially  approve  TIGR’s  use  over  wireless  tactical  networks.  In  an  initial  compromise 
agreement,  the  system  would  only  be  used  within  the  1st  Cavalry.  Funding  was  also 
limited.  However,  the  1st  Cavalry  found  the  capability  valuable  enough  that  it  provided 
some  of  its  own  funding.  DARPA  also  teamed  with  the  Rapid  Equipping  Force  (REF), 
which  sent  a  training  and  engineering  team. 


TIGR  gained  support  fairly  quickly  from  troops  in  the  field  but  somewhat  slower  from 
the  larger  Army  establishment.  Some  of  the  same  capabilities  that  make  it  useful  can  also 
cause  problems  with  Army  business  and  operational  practices.  For  example,  the  ability  to 
share  data  across  all  echelons  can  conflict  with  Army  rules  for  handling  classified  infor¬ 
mation.  In  addition,  TIGR  did  not  always  interoperate  easily  with  the  mainline  C2  sys¬ 
tems  at  the  battalion  level  and  above.  Continuing  collaborative  development  and 
refinement  were  needed.  This  work  was  facilitated  by  in-theater  teams  of  field  service 
representatives  and  system  engineers  responsible  for  fielding  and  maintaining  TIGR 
instances  throughout  Afghanistan  and  Iraq.  The  PM  also  ensured  the  availability  of 
training  in  support  of  theater  operations  and  the  maintenance  of  a  help  desk. 


Teamey  (2008) 
Turner  (2009). 
Turner  (2009). 
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From  the  foregoing,  we  can  see  that  TIGR  development  showed  many  features  associated 
with  a  complex  and  tightly  coupled  innovation  process,  of  the  kind  described  by  the 
Kline  model.  TIGR  originated  not  from  an  initial  discovery,  but  from  a  set  of  pressing 
needs.  Its  development  process  was  iterative  and  exhibited  considerable  feedback  loops 
between  stages.  There  was  a  particularly  important  feedback  loop  between  the  end  user 
(the  “market”)  and  the  first  conceptual  stage  driving  the  R&D.  The  PM  on  the  contractor 
side  described  TIGR  as  “something  completely  unique,  a  living,  breathing  system.”19  The 
innovation  process  also  exhibited  paths  into  the  global  scientific  knowledge  base  and 
initiated  some  new  research  in  a  number  of  areas.  One  such  area,  as  we  have  mentioned, 
involved  the  creation  of  a  distributed  architecture  with  policy-based  data  dissemination  to 
keep  the  bandwidth  load  on  the  tactical  network  low  and,  hence,  minimize  the  impact  of 
network  outages. 

Case  2:  Combined  Information  Data  Network  Exchange  (CIDNE) 


Introduction  and  Features 


The  CIDNE  is  a  Web-based  database  system  used  by  the  U.S.  military,  generally  at  bri¬ 
gade  level  or  above,  to  record  and  manage  infonnation  related  to  improvised  explosive 
devices  (IEDs).  CIDNE  offers  a  capability  for  tracking  three  types  of  entities — people, 
facilities,  and  organizations — that  influence  operations  in  a  region.  CIDNE’s  Web- 
enabled  Temporal  Analysis  System  (WebTAS)  is  a  suite  of  analytical  tools  that  allow 
users  to  combine,  visualize,  and  interpret  information  from  various  sources.  Using 

WebTAS  to  explore  the  CIDNE  database,  users  can  obtain  associated  data  on  explosive 

2 1 

hazard  events  throughout  the  theater  in  near  real  time.' 


Development 


CIDNE  was  developed  by  a  small  team  of  software  engineers  working  directly  with 
troops  in  the  field  to  fulfill  pressing  operational  needs.  The  development  process  was 
tightly  coupled  and  exhibited  Kline-like  feedback  loops  between  stages.  CIDNE  was 
developed  by  the  Anny’s  III  Corps,  with  the  encouragement  of  Central  Command. 
CIDNE  has  had  four  major  releases  since  fall  2006.  '  By  2009,  it  was  the  standard  IED 
activity  reporting  system  in  Iraq.23 


CIDNE  did  not  begin  as  a  counter-IED  system  but  evolved  and  was  repurposed  into  that 
role.  It  began  operational  life  as  a  local  C2  capability  at  a  division  command  center  and 
several  brigade  headquarters  in  Iraq  to  enable  information  management  and  sharing,  as 


Corrin  (2010). 

ISS  (2010);  Jean  (2010);  Wojciechowski  (2006);  Borgman  et  al.  (2009). 
Brady  (2009). 

Teamey  (2008). 

Walsh  et  al.  (2010). 
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well  as  storage  for  access  by  replacement  units.  Its  initial  focus  was  on  managing  bri- 
gade-and-above  contacts  and  coordination  efforts  with  the  Sons  of  Iraq  (Sol).25  The  445th 
Civilian  Affairs  Battalion  gave  the  technology  to  their  deploying  troops  and  encouraged 
its  use  in  Sol  engagements.  By  providing  a  standardized  reporting  framework  across  the 
intelligence  and  operations  disciplines,  CIDNE  brought  together  a  number  of  disparate 
communities.26  Its  role  expanded,  and  its  capability  to  track  people,  facilities,  and  organ¬ 
izations  proved  to  be  critical  in  the  burgeoning  effort  to  counter  IEDs.  CIDNE  thus  pro¬ 
vides  an  excellent  example  of  a  flexible  innovation  and  development  process  with  a  very 
strong  responsiveness  to  evolving  market  signals. 

Case  3:  Command  Post  of  the  Future  (CPOF) 

Introduction  and  Features 


The  CPOF  is  a  real-time  collaboration  technology  with  powerful  military  mapping  capa- 
bilities.  It  constitutes  a  virtual  “sand  box,”  where  commanders  can  publicly  depict  situa¬ 
tions,  plan  potential  courses  of  action,  offer  ideas,  refine  tasking,  and  synchronize  plans. 
Its  users  are  flag  officers,  unit  commanders,  and  senior  staff  at  several  echelons.  The  tool 
enables  commanders  in  dispersed  geographic  locations  to  visualize  the  battlefield,  obtain 
recent  information  about  operations,  and  make  annotations.  Users  can  communicate  and 
collaborate  without  leaving  their  operations  centers,  synchronizing  tactical  and  strategic 
activities  while  avoiding  the  hazards  of  travel.  CPOF  was  originally  a  DARPA  technol¬ 
ogy  demonstration  in  the  late  1990s  and  became  part  of  an  Army  Program  of  Record  in 
2006.  It  has  been  federated  with  the  Army’s  Maneuver  Control  System  (MCS)  and  con¬ 
sumes  data  from  the  Global  Command  and  Control  System  (GCCS).28  By  2009, 
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6,000  CPOF  systems  had  been  fielded  in  Iraq  and  Afghanistan. 


CPOF’s  main  human  interface  is  a  virtual  workspace  in  which  all  content  is  a  shared 
piece  of  data  in  a  networked  repository.  There  are  visual  representations  of  units,  events, 
tasks,  and  the  like.  These  appear,  for  example,  on  maps  or  schedule  charts.  In  addition, 
there  are  representations  of  whiteboard-like  hand  annotations  (e.g.,  brush-marks,  high¬ 
lighting,  and  notes).  Users  can  edit  data  values  (e.g.,  locations  on  a  map  or  tasks  on  a 
schedule)  by  dragging  and  dropping.  The  results  of  such  editing  are  visible  to  all  partici¬ 
pants  in  a  visualization  session.  When  one  user  moves  an  event  on  a  map,  for  example, 
that  event  icon  moves  on  all  maps  and  shared  views. 


Walsh  etal.  (2010). 
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The  Sol,  also  known  as  the  Sunni  Awakening  Movement,  are  coalitions  of  tribal  sheikhs  that 
have  taken  on  the  task  of  maintaining  security  in  their  communities. 

26  ISS  (2010). 

27  Croser  (2006);  Ebbutt  (2007);  Schachtman  (2009). 

28  Walsh  etal.  (2010). 

29  Walker  (2009). 
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Development 


Before  the  Iraq  War,  DARPA  development  of  CPOF  concentrated  on  creating  the  most 
intuitively  possible  human-computer  interface  to  support  C2.  For  operational  use  in  a 
tactical  environment,  other  improvements  were  needed.  The  system  would  need  to  be 
hardened  significantly  and  made  more  stable.  It  also  needed  to  be  made  scalable  to  hun¬ 
dreds  of  users.  As  the  Army’s  1st  Cavalry  Division  began  deploying  to  Iraq,  DARPA 
began  a  serious  collaboration  with  the  Anny  to  make  the  necessary  enhancements.  Gen¬ 
eral  Peter  Chiarelli  understood  the  technical  issues  and  allowed  deployment  of  CPOF  at 
risk.30 


This  deployment  at  risk  meant  that  invaluable  experimentation,  with  Kline-like  feedback 
loops,  could  be  conducted  in-theater  to  guide  the  development.  DARPA  and  the  Army 
signed  a  Memorandum  of  Agreement  (MOA)  in  2004.  DARPA  would  continue  to  fund 
advanced  technology  research  required  to  harden  the  system  and  exploit  lessons  learned, 
while  the  Anny  would  fund  continued  fielding.  The  experimentation  in  theater  allowed  a 
disciplined  and  integrated  development  process  with  constant  feedback.  Software  devel¬ 
opers  were  not  the  only  ones  who  participated  in  this  process.  Some  very  high-level 
research  scientists  also  spent  some  time  in  theater.  As  with  TIGR,  CPOF  had  field  ser¬ 
vice  representatives  on  location  to  help  manage  the  process  and  collect  user  feedback.  As 
new  capabilities  were  added,  users  and  field  service  representatives  provided  more 
impressions.  This  feedback  allowed  software  developers  to  focus  on  the  most  important 
problems.  Since  resources  were  not  expended  on  an  enhancement  until  it  was  justified  as 
a  valid,  real-world  need,  the  feedback  loops  served  not  only  to  reduce  risk,  but  also  to 
reduce  cost. 

Not  only  has  CPOF  had  its  development  guided  by  user  feedback,  but  the  system’s  very 
structure  and  functionality  also  encourages  user  experimentation  and  edge  innovation. 
CPOF  users  at  any  level  can  assemble  their  own  local  workspaces  out  of  smaller  “tool- 
and-appliance”  capabilities.  They  can  create  their  own  quick  applications  for  purposes 
that  the  software  developers  might  not  have  anticipated  and  do  so  without  disrupting 
other  users.  In  addition,  CPOF  repositories  have  become  a  rich  source  of  empirical  data 
on  the  nature  and  specific  content  of  C2  business  processes.  This  is  a  powerful  require- 

32 

ments  definition  and  validation  mechanism  that  can  augment  anecdotal  evidence. 


Although  CPOF  was  becoming  a  successful  deployed  system  before  2006,  it  had  still  not 
gone  through  the  usual  requirements  and  acquisition  channels  and  was  not  a  formal  Pro¬ 
gram  of  Record.  Between  2004  and  2006,  there  was  an  overlap  in  DARPA  and  Army 
leadership  of  the  effort.  Among  other  things,  this  allowed  time  for  a  rationale  to  be 
developed  to  turn  CPOF  from  an  R&D  program  deployed  at  risk  into  a  fonnal  program 


Greene  et  al.  (2010). 

Gershon  and  Kolojejchick  (2005). 
Walsh  et  al.  (2010). 


9 


conforming  to  all  acquisition  regulations.  In  2006,  CPOF  was  integrated  into  the  Anny’s 
MCS  program.33 

Discussion 


Rapid  Innovation  and  Fielding  in  the  Context  of  U.S.  Military  Acquisition  Rules 


One  can  argue  that  current  formal  DoD  acquisition  processes  are  already  based  on  the 
concept  of  identifying  and  fulfilling  operational  needs.34  One  could  also  argue  that  the 
various  feedback  processes  in  the  Kline  Model  of  innovation  are  fully  compatible  with 
DoD  acquisition  regulations.  The  problem  is  one  of  time  scale.  For  the  types  of  capabili¬ 
ties  discussed  in  this  paper,  the  feedback  loops  operate  best  when  they  do  so  often  and 
fast,  with  a  minimum  of  formalism  and  with  as  few  bureaucratic  middlemen  as  possible. 
We  live  in  a  world  where  young  soldiers  are  used  to  seeing  new  generations  of  cellular 
phones  and  media  players  appear  over  a  time  span  of  several  months,  and  non-state 
adversaries  can  easily  and  inexpensively  acquire  advanced  information  technologies  that 
make  them  nimble  and  effective.  In  such  a  world,  formal  DoD  processes  for  identifying 
and  validating  operational  needs  can  take  longer  than  development  timelines  for  new  IT 
capabilities,  and  the  resulting  technologies  can  significantly  lag  the  operational  need/  In 
addition,  as  a  recent  report  by  the  National  Research  Council  (NRC)  put  it,  “Success  as 
determined  by  process  metrics  in  acquisition  does  not  necessarily  align  with  success 
metrics  based  on  the  timely  delivery  of  end-user  capability.”36 


U.S.  Army  Procedures  To  Accelerate  Fielding  of  New  IT 


The  U.S.  Army  has  developed  some  standard  operating  procedures  (SOPs)  to  support 
wartime  fielding  of  new  information  technologies.  Requirements  are  documented  as  an 
Urgent  Operational  Need  (UON),  which  may  be  joint  or  Service-specific.  In  some  cases, 
the  UON  can  describe  some  proposed  IT  to  fill  the  gap.  Once  a  UON  has  been  validated 
by  Anny  G-3,  resources  can  be  allocated.  The  process  up  to  this  point  can  take  60  days 
or  more,  depending  on  the  priority  of  the  requirement.  The  next  step  is  to  determine 
whether  the  UON  will  become  a  Program  of  Record  or  be  adopted  by  an  existing  Pro- 
gram  of  Record.  For  IT,  both  Army  G-3  and  Army  G-6  are  involved  in  the  process. 
IT  used  on  networks  must  be  certified  for  interoperability  with  existing  infrastructure  and 
systems,  which  can  take  a  year  or  more.  In  the  past,  requests  from  units  in  actual  combat 
did  not  appear  to  receive  special  priority.39  Thus,  even  the  accelerated  Army  pathway  for 
IT  can  be  long  and  involved.  The  transition  to  Program-of-Record  status  is  not  automatic, 


J  Greene  et  al.  (2010). 

34  For  example,  Matthews  (2004). 

35  Teamey  (2008);  NRC  (2010). 

36  NRC  (2010). 

37 

The  U.S.  Army  staff  organization  for  Operations  and  Training. 

38 

The  U.S.  Army  staff  organization  for  Communications  and  Electronics. 

39  Teamey  (2008). 
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nor  is  it  assured  to  take  place  within  a  given  time  frame,  even  for  very  useful 
technologies. 


At-Risk  Adoption  and  Bureaucratic  Resistance 


In  order  for  effective  development  of  the  types  of  C2  IT  we  have  been  considering, 
in-theater  experimentation  and  iteration  are  almost  essential.  It  is  difficult  to  conduct  such 
experimentation  and  development  within  the  Army’s  usual  time  scale  for  acquisition — 
even  its  accelerated  process  for  IT.  However,  commanders  are  sometimes  empowered  to 
assume  risks  and  allow  the  use  of  uncertified  systems  in  theater,  generally  with  approval 
of  the  relevant  Combatant  Command  (COCOM).  In  such  a  case,  the  operational  chain  of 
command  authority  is  effectively  trumping  the  usual  fonnal  acquisition  rules.40  For  all 
three  of  the  cases  discussed  in  this  paper,  commanders  approved  “at-risk”  operation  at 
some  point. 


Although  TIGR  and  CIDNE  could  be  deployed  because  commanders  approved  at-risk 
operation,  both  systems  continued  to  be  subjected  to  process  demands  for  further  certifi¬ 
cations,  recommendations,  and  validations.  The  DARPA  PM  in  charge  of  TIGR  was 
quoted  in  2010  as  saying  that  the  system  received  “a  lot  of  bureaucratic  pushback”  when 
it  first  began  deploying  in  2006.  She  also  said  “...every  6  months  or  so,  we  still  get  push 
back  because  we  are  not  a  PoR  [Program  of  Record].”41  In  2008,  the  U.S.  Army  Vice 
Chief  of  Staff,  General  Peter  Chiarelli,  made  much  stronger  statements.  He  characterized 
TIGR  as  a  technology  that  “forever  changed  our  Army,”  but  he  said  it  succeeded  “in  spite 

42 

of  everything  the  Army  could  do  to  stop  it.” 


The  Anny  and  most  of  the  DoD  still  find  it  difficult  to  strike  a  balance  between  the 
importance  of  protecting  networks,  enabling  IT  platforms  to  share  information,  and 
rapidly  supplying  units  in  combat  with  capabilities  they  need.43 


Interoperability 


It  is  easy  to  criticize  the  DoD’s  acquisition  rules  as  cumbersome  and  inappropriate  for  the 
information  age.  It  is  also  easy  to  advocate  that  all  IT  development  be  allowed  to  follow 
Kline-like  innovation  paths  with  more  of  a  commercial  industrial  character.  However, 
this  type  of  innovation  can — sometimes  unwittingly — have  downsides.  For  example, 
interoperability  is  one  problem  that  might  be  aggravated  when  technologies  are  devel¬ 
oped  rapidly  and  somewhat  independently  to  fill  pressing  battlefield  needs.  This  is  not  to 


Resource  constraints  often  prevent  wider  adoption  of  a  technology  outside  of  the  initial 
theater. 

Magnuson  (2010). 

Clark  (2008). 

It  is  worth  noting  that  the  U.S.  Marines  and  Special  Forces  have  been  somewhat  more 
successful  with  their  processes  for  rapid  certification  for  information  technologies. 
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say  that  DoD  systems  developed  according  the  letter  of  all  the  acquisition  rules  are 
always  interoperable.  It  is  also  not  to  say  that  the  more  freewheeling  development  we 
have  discussed  must  necessarily  lead  to  systems  that  are  not  interoperable.  However,  this 
type  of  development  perhaps  introduces  more  of  that  risk.  Interoperability  with  mainline 
C2  systems  has  been  a  continuing  problem  for  CPOF,  for  example.  A  recent  study  has 
also  found  low  levels  of  semantic  interoperability  among  TIGR,  CIDNE,  and  CPOF.44 


Security 


Security  is  another  important  concern.  We  have  already  mentioned  the  conflict  between 
TIGR’s  widespread  horizontal  sharing  of  information  and  Army  procedures  for  safe¬ 
guarding  classified  information.  It  is  also  conjectured  that  one  of  the  main  unauthorized 
releases  of  classified  infonnation  to  the  Wikileaks  Web  site  in  2010  originated  in  Central 
Command’s  CIDNE.  It  is  possible  that  the  alleged  leaker  used  CIDNE’s  “Export  to 
Excel”  feature  to  capture  the  infonnation  that  he  later  illegally  transmitted.45  Using  this 
feature  apparently  did  not  leave  a  signature  that  was  easily  noticed  as  being  dangerous, 
because  the  process  is  used  routinely  for  legitimate  data  exchange.  In  fairness,  we  should 
emphasize  that  such  an  insider  attack  could  foil  many  systems,  including  ones  that  were 
procured  following  all  formal  procedures.  Perhaps,  though,  it  is  possible  that  rapid, 
Kline-like,  quasi-independent  development  of  an  IT  could  introduce  more  such  vulner¬ 
abilities.  Is  it  possible  that  a  more  deliberately  planned  and  more  robust  CIDNE  could 
have  thrown  up  more  flags  when  it  detected  large  data  exports  under  certain  conditions? 


Development  in  a  War  Zone 


The  rapid,  iterative  development  of  new  military  IT  capabilities,  with  considerable  gui¬ 
dance  from  user  feedback,  almost  necessitates  in-theater  experimentation.  Thus,  devel¬ 
opment  is  occurring,  at  least  to  some  extent,  in  a  war  zone.  This  development  approach 
raises  a  number  of  unique  challenges  and  issues.  For  one  thing,  soldiers  are  very  busy, 
and  do  not  necessarily  have  large  amounts  of  time  to  devote  to  the  process.  For  another 
thing,  developers,  engineers,  and  scientists  are  not  generally  soldiers,  and  it  may  be  diffi¬ 
cult  to  deploy  them  to  such  an  environment.  These  challenges/issues  do  not  make  the 
process  impossible,  but  they  do  make  it  difficult  and  risky  for  all  concerned.  Thus,  Kline- 
like  in-theater  development  is  hardly  an  innovation  process  that  can  be  considered 
routine. 

Summary  and  Conclusions 

In  a  world  of  rapidly  advancing  commercial  technology,  the  U.S.  military  often  still 
struggles  to  deliver  state-of-the  art  infonnation  technologies  for  C2  to  warfighters  and 
commanders.  Some  recent  success  stories  include  the  TIGR)  system,  the  CPOF,  and  the 
CIDNE. 


Lichtblau  and  Bleach  (2010). 
Dubaz  (2010). 
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These  cases  shared  some  important  characteristics  in  their  development: 

•  They  were  driven  by  the  need  to  solve  immediate  and  pressing  battlefield  prob¬ 
lems.  Sometimes  they  existed  first  as  research  programs,  but  it  was  only  after  the 
battlefield  driver  was  added  that  they  achieved  their  true  and  current  fonn. 

•  The  development  process  acted  to  fill  the  battlefield  needs  as  quickly  as  possible, 
by  taking  advantage  of  what  users  were  already  doing  or  trying  to  do,  by  using 
commercially  available  technology  when  appropriate,  and  by  allowing  users 
scope  to  innovate  (edge  innovation). 

•  The  systems  were  developed  with  constant  and  considerable  user  feedback, 
enabled  by  in-theater  experimentation. 

•  The  combination  of  forward  engineering  development  and  user  feedback  some¬ 
times  led  to  new  technology  being  required,  thus  driving  a  more  basic  level  of 
R&D  or  a  more  fundamental  interaction  with  the  base  of  stored  scientific 
knowledge. 

The  development  processes  of  these  systems  can  be  characterized  using  a  Kline  Chain- 
Linked  model  of  innovation,  involving  feedback  loops  between  the  various  stages  of  the 
innovation  process,  with  a  particularly  important  feedback  loop  between  market  signals 
and  the  early  conceptual  stages  of  development.  The  Kline  model  is  probably  not  gener¬ 
ally  applicable  to  large  defense  acquisition  programs  but  can  be  useful  in  the  case  of  an 
individual  IT  capability  being  developed  for  end  users.  Although  the  analogy  with  com¬ 
mercial  industry  is  not  exact,  the  end  users  constitute  the  “market.” 

A  number  of  consequences  flow  from  the  application  of  such  an  innovation  process  in  a 
military  IT  system: 

•  The  need  for  in-theater  experimentation,  combined  with  the  need  for  rapid  results, 
means  that  development  may  depend  on  an  “at-risk”  adoption  by  commanders, 
temporarily  trumping  the  normal,  lengthy  military  requirements  and  acquisition 
process.  Considerable  support  from  at  least  some  people  at  high  levels  in  the  hier¬ 
archy  may  be  necessary  for  this  to  happen. 

•  The  necessity  of  achieving  rapid  usefulness  and  meeting  the  needs  of  a  particular 
constituency  can  lead  to  development  of  systems  with  some  “stand-alone”  charac¬ 
ter,  forming  the  basis  for  future  interoperability  problems. 

•  The  same  necessities  can  also  lead  to  potential  security  problems.  Systems 
designed  for  broad  use  and  enabling  a  large  amount  of  information  sharing  can 
conflict  with  regulations  and  practices  for  handling  sensitive  information. 

•  The  need  for  considerable  user  feedback  to  perfect  the  system  and  make  it  rele¬ 
vant  can  place  a  burden  on  end  users  who  are  busy  with  life-and-death  decisions 
and  operations.  It  can  also  place  a  burden  on  scientists  and  engineers  who  are  not 
accustomed  to  working  in  a  war  zone. 

Overall,  the  U.S.  Army  and  most  of  the  DoD  still  find  it  very  difficult  to  strike  a  balance 
between  the  importance  of  protecting  networks,  enabling  IT  platforms  to  share  informa¬ 
tion,  and  rapidly  supplying  units  in  combat  with  capabilities  they  need.  However,  despite 
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the  many  problems  they  encounter,  “Kline-like”  iterative  innovation  processes  for  new  IT 
capabilities  have  shown  promise. 
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